Automated plant control systems (e.g., TDC 2000 or TDC 3000 Industrial Automation Systems manufactured by, and commercially available from, HONEYWELL INCORPORATED of Phoenix, Ariz.) include a comprehensive set of algorithms and auxiliaries to control and monitor various processes within, for instance, a manufacturing facility. The control systems can be tailored to satisfy a wide range of process requirements globally or within specified portions of the facility. Conventionally, the control systems include a plurality of modules, each having its own hardware, firmware and software, linked together by a communication bus thereby resulting in a distributed process control system. The distributed nature of the system affords high performance with the capability to expand the system incrementally to satisfy growth or modifications in the facility.
A first objective of automated plant management is to provide a control scheme that synthesizes plant-wide control of all processes therein to improve an overall efficiency of the facility. A second objective is to couple the control scheme to the facility by providing a real time data acquisition and monitoring scheme that monitors the operation of the facility by collecting historical and real time data and responding to deviations from desired operation that may arise and displaying the data for the benefit of an operator.
Regarding the first objective, U.S. Pat. No. 4,607,256 (previously incorporated) provides a plant-wide system for monitoring and controlling an industrial and electrical utility plant, including communication within the system and the related management of the processes within the plant. More specifically, the plant management system incorporates a "token-passing" arrangement employing separate modules of various types. A module transmits information to or receives information from another module located on a common bus. Each of the modules functions as a peer within the network and is assigned an individual network address. A token passed among the modules gives the module that possesses the token the right to access the bus and transmit a signal to the address of another module located on the bus. Automated control systems, such as the one disclosed in U.S. Pat. No. 4,607,256, are well known in the art.
Regarding the second objective, it is important to have access to current data concerning the operation of the plant and to display that data in a meaningful and useful manner to the operator. Toward this objective, the prior art has provided user interfaces that include visual displays that are graphical in nature, keyboards, pointers, touch-sensitive screens and the like. The conventional displays, as an example, contain graphical representations of devices in the plant (such as vats, pipes, pumps, etc.); operational or historical data associated with the devices are associated with the graphical representations to complete a visual paradigm for the operator.
Unfortunately, the process of creating routines or files to generate user interfaces, such as visual displays, historically has been complex and involved. To continue with the visual display example, it requires the use of conventional computer languages wherein basic graphical elements (such as points, lines or curves) are first required to be defined and then placed relative to one another to represent the devices in the plant (such as the vats, pipes or pumps). Even with the advent of conventional object-oriented programming languages, wherein the process plant devices are represented as objects consisting of their constituent basic graphical elements and wherein devices are recursively grouped into sets to form an entire visual display object file, the process of creating the file to generate a visual display has remained difficult and expensive. Of course a similar scenario may be delineated for any conventional user interface.
A substantial number of existing plant control systems use user interfaces object files developed by means of the conventional object-oriented programming languages. When considering whether to upgrade these existing systems, owners of the existing systems are reluctant to dispose of the object files in which they have invested heavily and that are reassuringly familiar to system operators. The owners would much rather upgrade invisibly and automatically to a different, possibly more technologically advanced or user friendly, retaining the "look and feel" of the user interface of their existing systems at minimal cost.
What is needed in the art is a system and method for emulating the existing system on which the object files were designed to run to avoid the expense of manual translation or redevelopment of the same.